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SUMMARY 

A real-time Sensor Failure Simulator (SFS) was designed and assembled for 
the Advanced Detection, Isolation, and Accommodation (ADIA) program. Various 
designs were considered. The design chosen features an IBM-PC/XT. The PC Is 
used to drive analog circuitry for simulating sensor failures In real-time. A 
user defined scenario describes the failure simulation for each of the five 
Incoming sensor signals. Capabilities exist for editing, saving, and retriev- 
ing the failure scenarios. The (SFS) has been tested closed-loop with the 
Controls Interface and Monitoring (CIM) unit, the ADIA control, and a real-time 
F100 hybrid simulation. From a productivity viewpoint, the menu driven user 
Interface has proven to be efficient and easy to use. From a real-time view- 
point, the software controlling the simulation loop executes at greater than 
100 cycles/sec. 


INTRODUCTION 

This report describes a general purpose device which can simulate sensor 
failures In control systems. This device, called the SFS, Is personal computer 
based, programmable, reliable, and flexible. It also provides repeatable fail- 
ure simulations. With these features the SFS can be used to efficiently eval- 
uate and demonstrate sensor failure detection logic. The SFS Interface 
Includes five separate analog signal flow paths through the device with Inde- 
pendent digital control of modifications (l.e., sensor failures) made to the 
analog signals. The first application of the SFS Is simulation of sensor fail- 
ures for the Advanced Detection, Isolation, and Accommodation (ADIA) program 
(ref. 1). 

The goals of the ADIA program are to develop, Implement, evaluate, and 
demonstrate an ADIA algorithm. The development and real-time Implementation of 
the algorithm are described In reference 1. Algorithm performance was evalu- 
ated using a real-time hybrid computer simulation of the F100 engine, the sen- 
sor failure simulator, and the ADIA control (ref. 2). Finally, the algorithm 
will be demonstrated on a full scale Pratt and Whitney FI 00 engine In the Lewis 
Research Center's altitude facility. Both the ADIA control and the sensor 
failure simulator will be used In this demonstration. 
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This report describes the SFS which was developed for the ADIA program. 
Included Is a discussion of the design requirements as well as system concept 
and philosophy. This Is followed by a description of the hardware and the soft- 
ware design. Finally a guide to operations for the simulator Is given. 


REQUIREMENTS 

The SFS was developed for the ADIA program. The ADIA control currently 
uses signals from five sensors: fan shaft speed (Nl), compressor shaft speed 

(N2) , combustor exit pressure (PT4), low turbine exit pressure (PT6), and low 
turbine Inlet temperature ( FTIT) . The SFS was designed to modify any combina- 
tion of the five ADIA sensor signals and send the modified (or failed) signals 
to the ADIA control system under experimental test conditions. In order for 
the SFS to properly perform this task, certain Initial design requirements had 
to be met. 

The first requirement for the SFS was that It must model failures accord- 
ing to the following equation: 

Yout = (scale factor • y^ n ) + bias + noise 

This equation describes a failure as the sum of: a scale factor multiplication 

of the Incoming sensor signal, a bias (step + ramp), and random white noise. 

By modeling failures In this manner (fig. 1), the SFS should allow a user to 
simulate most of the types of failures observed In engine sensors. 

The next requirement Imposed on the SFS was an ability to maintain signal 
Integrity. The signals leaving the SFS must be the same as the In-coming sig- 
nals In a normal/unfalled mode. If a discrete system Is chosen, there should 
be no significant sampling delay. Safety Is also an Important consideration. 

A device failure, such as loss of power to the SFS, must not disrupt signal 
flow In the normal mode. 

It was also required that the SFS be a stand alone, portable unit. The 
simulator will be required to perform Its task In several facilities. It must 
first be located In the hybrid simulation facility at Lewis where It will be 
validated. After validation In the hybrid lab, the simulator and control will 
be moved to the Propulsion Systems Laboratory at Lewis. In this facility the 
SFS will be used to test the ADIA control on a full scale FI 00 engine. It Is 
desirable that no disassembly/assembly need take place during this transition. 

Another requirement was that the SFS have a convenient user Interface with 
reasonable programmability. The SFS should be simple to use and It should 
provide for a high degree of productivity In an environment where overhead 
costs are substantial. The time required to prepare a failure scenario between 
data points should be minimal. 

Finally, the SFS should demonstrate reliability, maintainability, predict- 
ability, and repeatability. The SFS should be reliable, having a high mean 
time between failures. Safety Is a major concern when testing a full-scale 
engine. A reliable simulator will be necessary to limit the risk Involved when 
testing the ADIA control with the F100 engine. During testing, engine sensor 
signals will be failed Intentionally to check the fault accommodation and 
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detection of the control. These actions may be catastrophic to the engine, 
especially If valid engine sensor signals are not available at all times. For 
these reasons, the design must meet the safety requirements of the Lewis safety 
committee. Also, overhead costs tend to be high In an experimental environment. 
Therefore, It was desirable to choose a design which could be easily maintained, 
thus reducing downtime. A modular design would meet this requirement. Pre- 
dictable and repeatable performance Is also necessary as a basic characteristic 
for a good research tool. 

As a final requirement, development time for the SFS must be within the 
constraints of the ADIA program schedule. This would suggest a design which 
would be based primarily on commercially available hardware. 


SYSTEM CONCEPT AND PHILOSOPHY 

Various conceptual designs were suggested for the SFS. In all of the 
designs a common underlying philosophy was evident. This philosophy addresses 
the failure modeling and the signal Integrity requirements by combining a fail- 
ure scenario controller with a direct analog signal path (fig. 2). The general 
concept Is to model failures using analog circuitry and to determine the size 
and timing of the scale factor, bias or noise failure components using the 
scenario controller. It was decided early In the design process that digital 
sample and hold hardware could not be permitted In the direct signal flow path 
for both safety and performance reasons. 

To ensure signal Integrity during normal operation or In the event of a 
loss of power to the SFS the following approach was adopted. Failure simula- 
tion Is Initiated by a relay contract closure and terminated In the same man- 
ner. The normally open relay contracts allow a direct, uninterrupted, signal 
path during normal unfalled operation. 

Four possible designs were suggested and studied for their ability to meet 
the specified design requirements. The four designs were: (1) custom micro- 

computer driven analog hardware, (2) personal computer driven analog hardware, 
(3) analog computer driven analog hardware, and (4) programmable controller 
driven analog hardware. 

Each of the designs was considered for Its ability to meet the simulator 
design requirements. The custom microcomputer based design met all require- 
ments except for development time constraints. It was not possible to build 
and test the microcomputer design within scheduled deadlines. The personal 
computer-based design met all of the design requirements. Required digital to 
analog Interface hardware was available "off the shelf." Custom development 
would Include the software, and analog summing circuit, and a communications 
circuit for Interfacing the PC with the Control Interface and Monitoring (CIM) 
unit (ref. 3). It was determined that this development could be accomplished 
within the necessary time constraints. The strictly analog design had several 
deficiencies. The analog computer tends not to be user friendly and available 
hardware Is not portable. Also repeatability and reliability are difficult to 
obtain. The programmable controller based design was also determined to be 
undesirable. The available programmable controller was designed for processes 
with fixed logic. It was not designed to allow for program changes during 
execution. 
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Based on the above requirements analysis, the PC/analog design was chosen 
for the SFS. This design met all of the stated design requirements. Addi- 
tionally, this design has the flexibility and generality to be used In other 
failure detection studies and/or allow simulation of various other failure 
models. 


HARDWARE DESIGN 

The design chosen for the SFS was based on a personal computer (PC) 
Interface/controller driving analog signal processor hardware. The PC used for 
the SFS Is a standard configuration IBM-PC/XT expanded to 640K bytes of memory. 
An AST Six Pack/Plus expansion board was used for memory expansion. The AST 
board also contains a clock which Is used by the SFS software. An expansion 
chassis with a PC Interface houses most of the analog failure circuitry. This 
circuitry Is described In detail throughout the remainder of this section. 

Figure 3 Is a block diagram of the SFS hardware design. Three general 
observations can be made about this design. First, the five engine sensor 
signals are direct Inputs to the normally closed terminals of the ERB-24A 
switch matrix. In the normal/unfalled mode, each of the engine signals com- 
pletely bypasses the SFS and proceeds through the common terminals of the 
switch matrix to the ADIA control. Second, the simulator may modify any number 
of the five sensor signals by adding scale factor or bias errors to the ori- 
ginal signal. A noise error may also be Imposed on the any of the five sensor 
signals, however It may be added to only one channel at a time. These modified 
signals are fed to the normally open (NO) terminals of the switch matrix. The 
computer may then select either a modified, or an unmodified signal for each of 
the ADIA controller's five Inputs. Third, the five engine signals are electri- 
cally dlffernetlal with no reference ground. The modified signals must be com- 
patible In order to replace the unmodified signals. The simulator signals are 
transformed Into virtual-differential signals In the circuitry which combines 
the contributions of the three error components: scale factor, bias, and noise. 

These components are each produced In slightly different ways. 

The scale factor error, or multiplication of the Incoming signal by a 
constant, Is generated by using a METRABYTE DAC-02 multiplying dlgltal-to- 
analog converter (MDAC) for each channel. The MDAC has two Inputs, an analog 
signal (In this case, one of the five engine signals) and a digitally encoded 
number which the MDAC receives from the PC. The MDAC produces an analog volt- 
age output equivalent to the product of Its Inputs. Each DAC-02 circuit board 
contains two MDACs . Thus, to cover the five engine signals, three DAC-02's 
must be employed. 

The bias errors for the five signals are generated using a METRABYTE 
DDA-06 dlgltal-to-analog converter (DAC). The DAC receives a digitally encoded 
number from the computer representing the amount of bias to be added to the 
In-coming analog signal, and generates an analog voltage. In the range ±10 V, 
proportional to this number. The DDA-06 provides six such DAC's, which leaves 
one spare channel for future use. 

The noise error Is generated by a commercially available analog random 
noise generator. The output from the noise generator Is scaled using the 
spare MDAC from the scale factor circuitry. The output from the MDAC Is then 
switched to any one of the five engine signals using spare relay channels on 
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the switch matrix. These spare relay channels are labelled ERB-24B In 
figure 3. Both the switch matrix and the MDAC receive their commands from the 
computer. Since only one noise signal Is generated, only one of the five 
engine signals can be modified using all three error components, at any one 
time. The other four signals can be provided with any combination of scale 
factor, and biasing errors. 

For each of the five signals, the modified engine signal Is generated by 
summing contributions from the scale factor, bias and noise error components; 
using an analog summing circuit, as shown In figure 4. This circuit was repli- 
cated exactly for each of the five channels. It Is a standard design, using 
Zener diodes to limit the summed voltages to ±10 V maximum; and providing a 
virtual-differential output voltage to the switch matrix. The second op-amp In 
figure 4 Is provided so that the summation Is not Inverted. 

The DACs, MDACs and a custom analog signal processor board are found In 
the expansion chassis. A layout of the expansion chassis Is shown In figure 5. 
There are two unused card slots In the expansion chassis, but only one unused 
connector location, since the analog signal processor (ASP) board requires two 
connectors . 

A block diagram of the ASP board Is shown In figure 6. At connector AJ1 
are the ten lines representing the five differential Input engine signals. 

Each pair of these lines Is an Input to a Burr-Brown 3630 Instrumentation 
Amplifier with unity gain. The resulting output, a single-ended signal Is one 
of five output signals at connector AJ2. Also at connector AJ2 are 15 lines 
(five triplets) representing signals from the three failure components. These 
signals for scale factor error, bias error, and random noise are summed by one 
of the five summing circuits as described previously. The five resulting 
virtual-differential modified engine signals are then wired via ten lines to 
connector AJ1 . The ASP board contains the components and wiring for the five 
Instrumentation amplifiers, and the five summing and Isolation amplifiers. 

The ASP board also contains circuitry for a communications Interface 
between the Control Interface and Monitoring (CIM) unit and the SFS. This 
application specific hardware Is provided as a means of synchronizing the 
beginning of failure simulation with the beginning of data taking In the con- 
trols computer. A D/A converter on the controls computer Is used to send a 
start signal to the SFS Interface circuitry (fig. 7). On the ASP board, the 
start signal Is first converted from a differential signal to a single-ended 
signal using an Instrumentation amplifier. A comparator Is then used to detect 
when the start signal Is high and to convert It to TTL levels. Finally, the 
output of the comparator Is sent to Port C of the 8255 chip on the DDA-06 board 
where It can be detected by the SFS software. 

The switch matrix chosen for this simulator Is the METRABYTE ERB-24. The 
ERB-24 provides 24 channels of double pole/double throw relays. Ten of these 
relays are used by the SFS. Of all the components selected, the ERB-24 Is the 
only one which does not reside on the PC bus. Due to Its size this component 
required a separate chassis. All Interface wiring Is done Inside this chassis. 
The end panel for the ERB-24 chassis Is shown In figure 8. The eight connec- 
tors labeled AJ1 , AJ2, MJ1 , MJ2, MJ3, Ell, DJI, and E01 correspond to the two 
connectors for the ASP board, the connectors for the three DAC-02 MDAC boards, 
the engine signal Input connector, the connector for the DDA-06 DAC board, and 
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the engine signal output connector, respectively. The pin assignments for 
these connectors are shown In tables I to VI. 


SOFTWARE DESIGN 

The SFS software was conceived as a menu driven program which would provide 
four distinct capabilities: on-line program Instruction, storage and retrieval 

of failure scenarios, editing of failure scenarios, and real-time control of 
the analog failure simulation hardware. The Instruction capability was to be 
designed as a means of providing operational Instructions during program execu- 
tion. These Instructions should be both general and specific so that the SFS 
would be as self contained as possible. The store/retrieve capability was to 
allow the user to store and retrieve pre-deflned failure scenarios. This cap- 
ability would help provide the repeatability and high productivity so desired 
In a research environment. The means of defining and modifying failure sce- 
narios were provided by a failure scenario editor. This editor was to provide 
an efficient and user-friendly method of modifying any or all of the components 
which combine to form a failure scenario: the scenario description, the 

falled/unfalled channels, the nominal and maximum channel values, the failure 
delay for each channel, and the constants associated with the scale factor, 
step, ramp, and noise failure modes. The simulation portion of the software 
was assigned the task of real-time failure simulation based on Information 
contained In any given failure scenario. This task was to Include software 
which would scale failure scenario parameters. Initialize the analog hardware, 
and begin execution of real-time failure simulation based on a cue from the 
CIM unit. 

Although not In the original conceptual design, a fifth task was added to 
the SFS software during development. This task provides the user with the 
ability to trip relays or to set D/A constants directly from the keyboard. 

This task was Included to facilitate debugging of the hardware and software. 

Once the general conceptual design for the SFS software was established 
(fig. 9), the next step was to choose a method of Implementation which would 
provide for a highly efficient user Interface. A menu driven approach was 
chosen. This type of approach Is very efficient If the program execution can 
be described as a type of decision tree with a limited number of branches at 
any node. This was the case for the SFS as It was conceived and this was the 
approach taken during Implementation. 

The SFS currently makes use of 15 menus and numerous other prompts to 
accomplish Its tasks. The user Interface has proven to be very efficient and 
user-friendly. The scenario store/retrieve capability, while slightly cumber- 
some, provides the user with readable, as well as retrievable, scenario 
descriptions. The editor Is easy to use, and very efficient due to the exten- 
sive use of function keys for Input. The transient capability Is able to pro- 
vide the desired resolution during simulation, 2 to 9 msec. And the test 
capability has already proven useful In debugging both hardware and software. 

Since the sensor failure simulator hardware was being Implemented with an 
IBM-PC/XT as the user Interface, a standared PC language was required to Imple- 
ment the software. The primary language chosen for Implementation of the SFS 
software was FORTRAN. In particular, Ryan-McFarland Corporation's IBM Pro- 
fessional FORTRAN (version 1.00) compiler was used to produce the executable 
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code. This version "Is an Implementation of the full standard ANSI X3. 9-1978 
with extensions" (ref. 4). These extensions Include utilities for obtaining 
the date and time from the Disk Operating System (DOS) clock. 

As a secondary language, IBM Macro Assembler was chosen (ref. 5). FORTRAN 
does not have Inherent In It the ability to Interface with real-time hardware. 
Therefore It was necessary to write some assembler code for driving the analog 
circuitry and for Interfacing with the CIM unit. To obtain higher resolution 
than was available from the DOS clock, It was also necessary to write an 
assembly language routine that would read the real-time clock on the AST memory 
expansion board. The 1 msec resolution available from the AST clock yields 
smooth failure transients relative to the control update cycle. 

The SFS source code, about 8000 lines, Is currently divided Into 47 DOS 
text files which occupy approximately 182 Kbytes of hard disk storage. The 
FORTRAN code Is contained In 42 files; one file for the main program (SFS. FOR), 
33 files for subprograms, and nine files for common blocks. Common blocks are 
stored In separate files and Included by the compiler during compilation. Four 
of the remaining five files contain subprograms written In Macro Assembler 
which provide hardware to hardware and software to hardware Interfaces. The 
last "source file" Is the file that contains the text for on-line Instructions. 
A subprogram source file name Is designated as the first eight letters of the 
subprogram's name. The extension ".FOR" Is used to denote a file containing 
FORTRAN source code; the extension ".CMN" Is used to denote a file containing 
a common block, and the extension ".ASM" Is used to denote a Macro Assembler 
source code file. Table VII lists the source code file names, the name of the 
subprogram contained In each file, and a brief description of each subprogram. 
Table VIII lists the names of files containing common blocks, the name of. the 
common contained In each file, and brief description of what Is stored In the 
common. Table IX shows the hierarchical structure of the SFS program. No 
attempt has been made to show multiple calls. 

The FORTRAN and the assembly language subprograms are compiled and assem- 
bled respectively. The object code produced by compilation of the main program 
Is stored In SFS. OBJ. Object code for the subprograms Is stored together In a 
single object library, SFS. LIB. This Is accomplished by using the library 
utility supplied with the Professional FORTRAN, version 1.10 of the IBM Library 
Manager. Executable code Is produced by using version 2.3 of the IBM Personal 
Computer Linker (ref. 4) and Is stored In SFS. EXE. 

The object code for the SFS Is contained In two files which require a 
total of approximately 182 Kbytes of hard disk storage. The object module of 
the man program, SFS. OBJ, requires about 5 Kbytes. The rest of the 182 Kbytes 
Is used for the object library, SFS. LIB. 

The last two files which are part of the SFS code are the file containing 
the executable Image, SFS. EXE, and the DOS text file containing Instructions 
for using the SFS, INSTRUCT.TXT. The executable code requires 147 Kbytes of 
storage and the Instruction file about 57 Kbytes. 


GUIDE TO OPERATION 

This section Is designed as a user guide for the SFS. In It the operation 
of the SFS Is described In detail. The first part of this discussion will deal 
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with directory and file structures. The later part of the section will discuss 
In-depth each of the various program menus. 

It should be pointed out at this time that only one failure scenario at a 
time resides In the PC's random access memory (RAM). This failure scenario Is 
called the current failure scenario. In most cases, the program will be work- 
ing on/with the current failure scenario. A default scenario Is defined during 
the program Initialization and becomes the current failure scenario until 
changed by the user or replaced by the retrieval of a stored scenario. 

It should also be pointed out at this time that some of the keys on the 
keyboard are "mapped" during execution. FORTRAN does not provide an Interrupt 
capability for reading the keyboard. As a result some of the keyboard keys are 
mapped or redefined to provide useful capabilities like one-stroke Input and use 
of function keys. A more In-depth discussion on this topic will be presented 
later In this paper. At this time the user Is to be warned about terminating 
program execution In an Irregular manner. The effects of the key mapping are 
such that. If execution Is terminated Irregularly, It may be necessary to 
reboot the PC to return all keys to their original key codes. 


Directory and File Structure 

Three files are used to run the SFS program. These files are SFS.BAT, 
SFS.EXE, and INSTRUCT.TXT; SFS.BAT resides In the directory \UTILITY on the 
PC's hard disk and Is the batch file which Initiates program execution. The 
second file mentioned above, SFS.EXE, contains the executable code and should 
be located In the directory \SFS. Also residing In the \SFS directory on the 
hard disk, Is the DOS text file, INSTRUCT.TXT, which contains text for on-line 
Instructions. 

Although the SFS program and Instructions are currently loaded from the 
hard disk drive, they may also be loaded from a floppy disk. In either case 
the directory and file structure should be the same as described above with 
the exception that the SFS.BAT file may be stored In the floppy's root 
directory. 


v Initiating Program Execution 

Initiate program execution by typing "SFS" In response to the DOS prompt 
from anywhere but the \SFS directory. To get a printer listing of stored 
scenario files (.SFS extension) before Initiating program execution, type 
"SFS /D" In response to the prompt. 

Upon receiving the "SFS" command, DOS begins executing statements from the 
SFS.BAT batch file (table XI). In lines 1 and 2, the ECHO and BREAK are turned 
off. In line 3, the DOS search path Is defined so that the search for an exe- 
cutable file proceeds from the current directory to the \SFS directory. Line 4 
of the batch file changes the DOS default directory to the \SCENARI0 directory 
where failure scenario files may be stored. Lines 5 and 6 check for the "/D" 
parameter. If It has been Included In the call to the batch file, a directory 
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listing of all stored scenario files Is routed to the printer. The SFS exe- 
cutable code Is loaded and program execution begins after the DOS command 
processor receives line 7. For further explanation of these commands see the 
DOS manual (ref. 7) . 

The SFS program begins by printing a title screen. This screen Is dis- 
played while program Initialization takes place. After Initialization Is com- 
pleted, this screen Is replaced by the program's main menu (fig. 10). 

The main menu presents the user with a list of six options: (1) Instruc- 
tions, (2) retrieve stored failure scenario, (3) edit current failure scenario, 
(4) run current failure scenario, (5) test SFS hardware/software, and (6) quit. 
There are two ways to choose an action Item from this menu. One way Is to 
enter the number associated with a desired action Item. Another way Is to 
choose the default action Item. 

The default Is displayed In reverse video. The default may be changed by 
pressing the up arrow or the down arrow on the keyboard. It may also be 
changed by entering the codes corresponding to these keys, "u<CR>" and "d<CR>'' 
respectively. The default may be selected by the carriage return/enter key. 


Instructions 

The first action Item In the SFS main menu provides the user with an 
on-line program reference. When the user chooses this action Item, Instruction 
text Is displayed. The first page of this text Is shown In figure 11. The 
user may page up and down through the text by pressing the PgUp and PgDn keys. 
Entering the code "b<CR>" of "f<CR>" will have the same effect. Other keys 
which may be used while In the Instruction facility are the Home and End keys. 
The Home key causes the Instruction facility to return to the first page of 
text. The End key causes the facility to proceed to the last page of text. 

The ASCII codes for these keys are "Home<CR>" and "End<CR>" respectively. The 
user may exit the Instruction facility by pressing a carriage return/enter. 

The text for the Instruction facility Is stored In the DOS text file 
INSTRUCT.TXT. It Is stored as a series of pages 80 columns wide by 22 lines 
long. Macros are provided for Including any ASCII character or sequence of 
characters In this text. These macros cause ASCII codes to be Inserted In each 
page of text as It Is read from the test file. Macros are listed In table XII. 
Note that while the macros are multiple characters, the number of characters 
displayed by the monitor will depend on the ASCII character or sequence of 
characters which define a given macro. Also, note all DOS control sequences 
must be followed by a space In the test. In particular, this applies to the 
$f, $b, $r, and $n codes. 

Storing and Retrieving Failure Scenarios 

The second action Item In the SFS main menu provides the user with cap- 
abilities for storing and retrieving failure scenarios from disk storage. 

When the user chooses this action Item the stored scenario menu Is displayed 
(fig. 12). 
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The stored scenarios menu presents the user with five action Items: (1) 

RETRIEVE, (2) DELETE, (3) REPLACE, (4) STORE, and (5) RETURN. These Items may 
be chosen In a manner similar to the SFS main menu. Note that the user may 
wish to return to the stored scenario menu without exercising the specified 
action Item; this may be accomplished by pressing the PgUp key or the PgDn key 
any time after an action Item has been selected. 

Action Item number one allows the user to retrieve, from a specified 
stored scenario file, any scenario which has been stored In that file. A stored 
scenario file Is any DOS text file In which only scenarios are stored or will 
be stored. One convention Is to use a .SFS extension for denoting a failure 
scenario file. When action Item one Is chosen, the user Is prompted for a file 
name. The default file name may be selected by pressing carriage return/enter 
or a new file name entered by the user. File names may be any valid DOS file 
name. If the file exists, the program will read the description of any sce- 
nario stored In this file and present the user with a list of the descrlptlon(s) 
(fig. 13). The user may then specify, by setting the default, which scenario 
the program should RETRIEVE. When the specified scenario has been retrieved, 
the program displays the new scenario description under the banner and returns 
to the stored scenario menu. 

Action Item number two allows the user to delete, from a specified stored 
scenario file, any scenario which has been stored In that file. When action 
Item two Is chosen, the user Is prompted for a file name. As with action Item 
one, the program will check for the files existence. If the file exists, the 
program will read the description of any scenario stored In this file and 
present the user with a list of these descriptions. The user may then specify, 
by setting the default, which scenario the program should DELETE. When the 
specified scenario has been deleted, the program returns to the stored scenario 
menu. 


Action Item number three allows the user to replace a stored scenario with 
the current failure scenario. When this action Item Is chosen, the user Is 

prompted for a file name. As with action Items one and two, the program will 

check for the files existence. If the file exists, the program will read the 
description of any scenario stored In this file and present the user with a list 
of these descriptions. The user may then specify, by setting the default, which 

scenario should be REPLACED by the current failure scenario. When the specified 

scenario has been replaced, the program returns to the stored scenario menu. 

Action Item number four allows the user to store the current failure 

scenario In a specified file. When this action Item Is chosen, the user Is 

prompted for a file name. The program will check for the files existence. If 
the file exists and the specified file has the capacity, the current failure 
scenario will be appended to the end of the file. There Is a limit of ten (10) 
failure scenarios per scenario file. If the file specified by the user does 
not exist, the program notifies the user and asks If It should create a new 
file. When the scenario Is stored, the user Is returned to the stored scenario 
menu. 


The user may return to the SFS main menu by selecting action Item five. 
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Creating/Editing a Failure Scenario 

The third action Item In the SFS main menu Is EDIT CURRENT FAILURE SCE- 
NARIO. When the user selects this action Item, the program enters the FAILURE 
SCENARIO EDITOR. 

The editor begins by displaying the description of the current failure 
scenario (fig. 14). At this time, the user may choose to accept the current 
description or replace It with a new description. Retention of the default 
description may be accomplished by pressing carriage return/enter . A new 
description may be defined by simply entering It from the keyboard. 

After the user enters a description, the editor centers It below the ban- 
ner and displays the Failed Channels menu (fig. 15). This menu allows the 
user to select which channels will be failed during simulation. Failed chan- 
nels are displayed In bold type; unfalled channels are displayed In normal 
type. Each channel may be toggled between failed and unfalled by pressing the 
number key corresponding to the given channel. A carriage return notifies the 
program that the user Is finished with this menu. 

The next two menus In the failure scenario editor are necessary to estab- 
lish the relationship between the SFS output voltages and the engineering units 
they represent. They allow the user to define the parameters of a failure sce- 
nario In engineering units. The first menu Is for specifying nominal channel 
values (fig. 16). Each channel's nominal value should be set to the value, In 
engineering units, represented by the Incoming sensor signal at run time. The 
second menu Is for specifying maximum channel values (fig. 17). Each channel's 
maximum value should be set to the value, In engineering units, which 
represents full scale. 

The constants associated with these menus may be changed In the following 

manner. First, set the default (reverse video) over the channel which will be 

modified. Use the up and/or down arrow key to set the default. Next, enter 
the new value of the constant followed by a carriage return. Pressing carriage 
return/enter by Itself, causes the editor to proceed to the next menu. Note 
that any channels defined as failed In the Channel Failure menu will be dis- 
played In bold text (high Intensity) In these menus. 

The failure delay menu (fig. 18) Is the next menu displayed by the editor. 

It Is functionally the same as the menus used to set nominal and maximum chan- 

nel values. This menu allows the user to specify, for each channel, some dead 
time at the beginning of the transient. Actual failure simulation on each 
channel will begin Immediately following the delay specified for that channel. 
This menu provides the user with the capability to simulate multiple offset 
failures . 

After exiting the failure delay menu the editor will begin to display a 
menu of failure modes and constants (e.g., scale factor, bias, ramp, and noise) 
for each failed channel (fig. 19). Beginning with channel one and continuing 
sequentially through channel five, these menus allow the user to specify the 
failure modes and associated constants which define how a particular channel's 
failure will be simulated. 
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The menu for each channel failed will display four failure modes and four 
associated constants. Note that any combination of active/inactive modes are 
possible and that the active failure modes are displayed In bold type. A fail- 
ure mode may be activated by simply depressing the associated number on the 
keyboard followed by a carriage return/enter. To modify the constant of a 
given failure mode, the user should enter the number corresponding to the fail- 
ure mode followed by a delimiter (space or comma) followed by the new value of 
the constant. Pressing carriage return/enter completes the sequence and the 
constant's old value Is replaced by the new. 

In these menus the scale factor mode Is always active and defaults to 
unity; the other modes may either be active or Inactive. The active scale 
factor mode causes a channel's Incoming signal to be multiplied by the scale 
factor constant. The value of scale factor constant may range between ±2. If 
the bias mode Is active. It has the effect of adding a step to the Incoming 
sensor signal. The height of the step Is the value of the bias constant which 
Is only constrained by the specified maximum channel value. If the ramp fail- 
ure mode Is active, a bias Is added to the Incoming sensor signal which varies 
linearly In time, the slope being the value of the ramp constant. If the noise 
mode Is active, the Incoming signal from the external noise generator Is multi- 
plied by the noise gain constant and added to the Incoming sensor signal. The 
noise gain constant Is limited to the range ±1. The noise failure Is allowed 
to be active on only one channel In the current failure scenario. 

A single carriage return/enter will cause the editor to check for errors 
In failure definition. First, the editor checks to see If the maximum channel 
value Is exceeded by the scale factor, step bias, or noise failures. If the 
maximum value Is exceeded, the editor presents the user with current maximum 
and a suggested maximum. The user Is asked If It Is acceptable to replace the 
current maximum with the suggested maximum (fig. 20). If the user chooses not 
to accept the computed maximum, the editor returns to the failure mode menu. 
This error checking takes place because the transient portion of the program 
limits the output signal to the maximum channel value In both the positive and 
negative directions. 

After conflicts with the maximum channel value have been satisfactorily 
resolved, the editor does some checking on the ramp failure mode. If the ramp 
failure mode Is active, the program will display the approximate time at which 
the ramp will reach the channel maximum (fig. 21). The user Is then prompted 
to accept the status quo. If the peak time displayed Is unacceptable, entering 
an "n<CR>" will cause the editor to return to the failure mode menu. If the 
peak time displayed Is acceptable, the editor moves on to the menu for the 
next failed channel. 

When menus for all failed channels have been completed, the editor per- 
forms one final error check. It was stated previously that noise may be 
defined on only one channel. The editor will check this condition. If noise 
has been defined on more than one channel, those channels are displayed In menu 
form (fig. 22). The user Is then asked to choose a single channel from the 
list. During run time, noise will only be added to the specified channel. 

When the editor determines that the scenario Is essentially without error. 
It queries the user one last time. This query allows the user to store the 
failure scenario just defined. If the editor receives a positive reply, the 
user will be prompted for a file name. The program will check for the files 
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existence. If the file exists and the specified file has the capacity, the 
current failure scenario will be appended to the end of the file. Remember, 
there Is a limit of ten (10) failure scenarios per scenario file. If the file 
specified by the user does not exist, the program notifies the user and asks If 
It should create a new file. When the scenario Is stored, the user Is returned 
to the SFS main menu. 

At this time more discussion should be Included about mapping keys to 
specified codes. Most of the key mapping mentioned earlier was Implemented 
specifically for the editor. Some keys are mapped to SFS Identifiable 
sequences of ASCII codes before entering a menu and remapped to the original 
single ASCII codes when exiting the menu. At other times during program execu- 
tion, a carriage return Is added to a key's ASCII code. This provides a cap- 
ability for one stroke Input (e.g., pressing key "1" becomes the same as 
pressing key "1" followed by a carriage return). Key mapping Is accomplished 
by the control codes listed In reference 6. At any time during execution an 
SFS Identifiable ASCII sequence may be entered as an alternative to pressing 
the key to which that sequence Is mapped. The ten function keys, as well as 
the Home, End, PgUp, and PgDn keys, are mapped to control codes recognized by 
the editor. These codes allow the user the freedom of moving between noncon- 
sectlve menus within the editor. This feature was added to enhance productiv- 
ity In the research environment. Table X contains a list of the function and 
keypad keys recognized by the editor, the codes which are mapped to these keys, 
and a short description of the keys functions. Figure 23 shows the function 
key template. 


Real-Time Sensor Failure Simulation 

The fourth action Item In the SFS main menu Is the heart of the SFS. This 
Is where the actual real-time sensor failure simulation takes place. When the 
user chooses this action Item the program requests permission to Initialize the 
D/A hardware (fig. 24). There are several places In this part of the program 
where the user may abort the simulation and return to the main menu; this Is 
the first. If the user enters a character other than "Y" or "<CR>" the program 
returns to the main menu. 

If permission Is granted by the user, the D/A hardware Is Initialize as 
follows. First, the multiplying DAC for the noise, MDACO, Is set to 0.0. 
Second, the scale factor MDACs for the five sensor signals are set to 1.0. 
Third, the bias DACs for the five sensor signals are set to 0.0. Forth, If the 
noise failure Is active for a given channel, the noise relay for that channel 
Is closed and all other noise relays are opened. Finally, If any channel has 
been defined as failed, the failure relay for that channel Is closed. At this 
point, the signal flow path of all failed channels Is redirected through the 
failure circuitry. The hardware Is ready to begin the simulation of sensor 
fallure(s) . 

After completing hardware Initialization, the program does some software 
Initialization. The failure gains specified for each channel are scaled and 
stored as run-time gains for output to the D/A hardware. Bias and ramp con- 
stants for channels 1 to 4 are scaled as follows: 

.. ,4 failure gain 

run- m g n - max ^ mum channel value 
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For channel five the maximum value must be converted, before scaling, from 
Fahrenheit to Rankin. The formula for scaling the bias and ramp constants 
then becomes: 


. . , failure gain 

run- me ga n - ( max ^ mum channel value + 459.67) 

Constants for the scale factor and noise failures are not normalized. 

When Initialization of the failure hardware Is complete and the run-time 
gains have been computed, the program queries the user once again (fig. 25). 
Here the user Is asked to specify how long the failure transient should run. 

If a carriage return Is depressed, the program uses the default displayed under 
the query. If a run time other than the default Is desired, that number may 
be entered from the keyboard. The software currently limits the run time to 
between 1 and 60 sec. Any Integer or real number within these constraints may 
be specified. 

After obtaining the length of the failure transient from the user, the SFS 
Is ready to run the current sensor failure scenario. The program now presents 
the user with three choices (fig. 26): (1) Begin Scenario, (2) Begin Scenario 

on signal from CIM, and (3) Return to Main Menu. The desired action Item Is 
specified by a two character sequence, the option number followed by a carriage 
return/enter. If the user chooses to return to the main menu, the failure 
relays are opened so that the sensors signals are restored to their Individual 
through flow signal paths. 

When the user chooses action Item number one, three things happen: the 

menu Is erased; the message "** RUNNING **" appears with flashing asterisks 
(fig. 27); the real-time failure simulation begins. There Is a lag of about 
100 msec between the time when the user enters the option number and the time 
that failure simulation actually begins. Most of this lag Is cause by output 
to the monitor. 

When the user chooses action Item number two a different sequence of 
events takes place. First, the current menu Is erased. Then, the program 
notifies the user that It Is waiting for a signal from the CIM unit to begin 
the simulation. When transient data taking Is Inltated by the CIM unit. It 
sends a signal to the SFS. The SFS takes this signal as Its cue to begin the 

simulation. An asterisk Is displayed under the wait message just before 

and during the real-time simulation (fig. 28). The dead time between the CIM 

signal and the beginning of the transient Is approximately 40 msec. 

Simulation begins by Inltallzlng the timer. After the timer Is Initial- 
ized, the program enters the simulation loop. The simulation loop begins by 
calling the timer. The timer returns the time, In seconds, that the simulation 
has been running (run time). From this time and the time read at the beginning 
of the previous loop a delta (dT) Is computed. At this point, the program 
begins to modify the constants of the D/A hardware. 

If a channel Is failed, and If the run time has just met or exceeded the 
failure delay, the MDAC for the noise, the MDAC for the scale factor, and the 
DAC for the bias are all set to their failed values. Next, If the channel Is 
failed and If a ramp failure has been specified, a new value Is computed for 


14 



the constant which Is output to the bias DAC. The new value for the constant 
Is computed as follows: 

run-time bias = run-time bias + (slope * dT) 

The variable slope on the right-hand side of the equation Is the ramp constant 
scaled by the maximum channel value. The value for the bias DAC constant Is 
then limited to values between ±1. After computing the new value for the bias 
DAC, It Is output to the DAC. This series of steps Is performed on channels 1 
through 5 sequentially. 

At the end of the simulation loop, the program saves the current run time 
and uses It to compute the next update Interval (dT). If the run time Is less 
than the time specified as the length of transient, execution continues at the 
beginning of the loop. When the run time meets or exceeds the length of the 
transient, the program exists the real-time loop and displays some statistical 
Information about the run (fig. 29). 

Note that this method of Implementation allows the simulation loop to run 
at the maximum speed of the PC. The dT will change with the number of opera- 
tions performed Inside the loop. The worst case scenario occurs when all five 
channels fall at T = 0.0 and all five channels exhibit scale factor, bias, and 
ramp failures. For this worst case scenario the statistics were found to be: 
maximum dT Is 0.009 sec, maximum dT occurs at 0.001 sec, and average dT Is 
0.005 sec. These figures are provided as a measure of the resolution of the 
simulation. 

The final screen displayed by this part of the program Is a menu provided 
for manually restoring channels to an unfalled state (fig. 30). It Is dis- 
played only If a failure has been simulated on one of the channels. Failed 
channels are displayed In bold (high Intensity) type. All channels MUST be 
restored to an unfalled state. A channel may be restored to Its unfalled state 
by entering the channel number from the keyboard, This trips the channel's 
relay which causes the sensor signal to be switched from the failed signal path 
to the through flow signal path. When all channels have been restored to an 
unfalled state, the program returns to the main menu. 


Testing the SFS Hardware 

The fifth action Item In the SFS main menu provides the user with the cap- 
ability to set the D/A hardware constants and trip noise and failure relays 
manually. Specifying this action Item causes the program to erase the main 
menu, to Initialize the D/A hardware, and to present the user with a menu 
similar to figure 31. This portion of the SFS was useful for debugging 
problems with both hardware and software. 

Before displaying the test menu, constants for the D/A hardware are 
obtained from the current failure scenario. These scaled values are then out- 
put to the DACs and MDACs. The position of the noise relays Is also set 
according to the current failure scenario. However, the failure relays are 
ALWAYS Initialized to an unfalled state. 
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At this point the menu Is displayed. If a DAC or an MDAC Is loaded with 
a nonzero constant, the Item will be displayed In bold type (high tensity). 
When relays which are positioned to a failed state are also displayed as bold. 

Constants may be checked or changed by entering a device number followed 
by a carriage return/enter. Following this sequence, the current value of the 
constant for the specified device Is displayed In the lower left corner of the 
monitor. Next a prompt for the device's constant and the limits of that con- 
stant are displayed. If only a carriage return Is entered, the value of the 
constant for the device In question remains unchanged. If a new value Is 
entered by the user, this value Is output to the proper device and displayed 
In the lower left corner of the monitor. Values which are out of range cause 
an error message to be displayed. 

The user may exit the test menu and return to the SFS main menu by enter- 
ing device number 99. Before returning to the main menu, the program returns 
all relays to an unfalled state. 


TERMINATING EXECUTION OF THE SFS 

The last action Item In the SFS main menu Is for terminating program exe- 
cution. When the user chooses action Item number six, the main menu Is erased 
and the user Is presented with the prompt "Exiting SFS: Are you Sure??." An 

affirmative reply from the user causes program execution to be suspended. A 
negative reply returns execution to the main menu. It Is STRONGLY SUGGESTED 
that program execution be terminated In this fashion. Terminating the program 
In any other manner may leave failure hardware In an undesirable state. . 
Improper mapping of keyboard keys Is also likely to occur If the program execu- 
tion Is terminated In an other than proper manner. 


SUMMARY OF RESULTS 

A real-time Sensor Failure Simulator was designed and assembled for the 
ADIA program. A personal computer-based design was chosen as the most favor- 
able approach. In this design special analog hardware, driven by an IBM-PC/XT, 
modifies five Incoming sensor signals to produce simulated sensor failures. 

A user defined scenario contains the Information which Is used by the SFS 
to simulate sensor failures. The model used for simulating sensor failures 
has three components: a scale factor component, a bias component (constant + 

variable), and a noise component. Capabilities exist for editing, saving, and 
retrieving the failure scenarios. 

The Sensor Failure Simulator has been tested closed-loop with the CIM, 

ADIA control, and a real-time F100 hybrid simulation. From a productivity 
viewpoint, the menu driven user Interface has proven to be efficient and easy 
to use. From a real-time viewpoint, the software controlling the simulation 
loop executes than 100 cycles/sec. 
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APPENDIX A 


TABLES 


TABLE I. - AJ1 PIN CONNECTIONS - 


PROTOBOARD DIFFERENTIAL SIGNALS 


Pin 

To 

Function 

1 

DJI— 22 

CIM READY 

2 

E I 1—1 5 

Channel No. 2 in (+) 

3 

E I 1—16 

Channel No. 2 in (-) 

4 

E I 1—18 

Channel No. 4 in (+) 

5 

E I 1—19 

Channel No. 4 in (-) 

6 

E01-25 

START from CIM (+) 

7 

E01-24 

START from CIM (-) 

8 

17-NOA 

Signal No. 1 out (+) 

9 

17-NOB 

Signal No. 1 out (-) 

10 

19-NOA 

Signal No. 3 out (+) 

11 

19-NOB 

Singal No. 3 out (-) 

12 

21-NOA 

Signal No. 5 out (+) 

13 

21-NOB 

Signal No. 5 out (-) 

14 

E 1 1—1 

Channel No. 1 in (+) 

15 

El 1-2 

Channel No, 1 in (-) 

16 

El 1-4 

Channel No. 3 in (+) 

17 

El 1-5 

Channel No. 3 in (-) 

18 

E 1 1—7 

Channel No. 5 in ( + ) 

19 

El 1-8 

Channel No. 5 in (-) 

20 

NC 


21 

NC 


22 

18-NOA 

Signal No. 2 out (+) 

23 

18-NOB 

Signal No. 2 out (-) 

24 

20-N0A 

Signal No. 4 out (+) 

25 

20-NOB 

Signal No. 4 out (-) 







TABLE II. - AJ2 PIN CONNECTIONS - 


PROTOBOARD SINGLE ENDED SIGNALS 


Pin 

To 

Function 

1 

1 

NOISE No. 1 

2 


NOISE No. 2 

3 


NOISE No. 5 

4 

NC 


5 

DJI-16 

BIAS No. 1 

6 

DJI-12 

BIAS No. 3 

7 

DJI-1 

Bias No. 5 

8 

MJ2-23 

SCALE No. 2 to adder 

9 

MJ3-23 

SCALE No. 4 to adder 

10 

NC 


11 

MJ1-16 

SCALE No. 1 from instr. amp 

12 

MJ2-16 

SCALE No. 3 from instr. amp 

13 

MJ3-16 

SCALE No. 5 from instr. amp 

14 

2-CA 

NOISE No. 2 

15 

4-CA 

NOISE No. 4 

16 

BNC (-) 

NOISE GROUND 

17 

DJI-14 

BIAS No. 2 

18 

DJI-2 

BIAS No. 4 

19 

NC 


20 

MJ1-17 

SCALE No. 1 to adder 

21 

MJ2-17 

SCALE No. 3 to adder 

22 

MJ3-17 

SCALE No. 5 to adder 

23 

NC 


24 

MJ2-22 

SCALE No. 2 from instr. amp 

25 

MJ3-22 

SCALE No. 4 from instr. amp 








TABLE III. - MJ1, MJ2, and MJ3 PIN CONNECTIONS - 
MDAC ( DAC-02 ) SCALE FACTOR SIGNALS 



Connector MJ2 

Pin 

To 

Function 

1-15 

16 

17 

18-21 

22 

23 

24-25 

NC 

AJ2-12 

AJ2-21 

NC 

AJ2-24 

AJ2-8 

NC 

SCALE No. 3 input to MDAC 
SCALE No. 3 output from MDAC 

SCALE No. 2 input to MDAC 
SCALE No. 2 output from MDAC 


Connector MJ3 

Pin 

To 

Function 

1-15 

16 

17 

18-21 

22 

23 

24-25 

NC 

AJ2-13 

AJ2-22 

NC 

AJ2-25 

AJ2-9 

NC 

SCALE No. 5 input to MDAC 
SCALE No. 5 output from MDAC 

SCALE No. 4 input to MDAC 
SCALE No. 4 output from MDAC 























TABLE IV. - Ell PIN CONNECTIONS - 


ENGINE INPUT SIGNALS 


Pin 

To 

Function 

1 

17-NCA, A01-14 

Channel No. 1 in (+) 

2 

17-NCB, AJ1-15 

Channel No. 1 in (-) 

3 

E01-3 

Channel No. 2 shield 

4 

19-NCA, AJ1-16 

Channel No. 3 in (+) 

5 

19-NCB, AJ1-17 

Channel No. 3 in (-) 

6 

E01-6 

Channel No. 4 shield 

7 

21-NCA, AJ1-18 

Channel No. 5 in (+) 

8 

21-NCB, AJ1-19 

Channel No. 5 in (-) 

9 

NC 


10 

NC 


11 

NC 


12 

NC 


13 

NC 


14 

E01-14 

Channel No. 1 shield 

15 

18-NCA, AJ1-2 

Channel No. 2 in (+) 

16 

18-NCB, AJ1-3 

Channel No. 2 in (-) 

17 

EOl-17 

Channel No. 3 shield 

18 

20-NCA, AJ1-4 

Channel No. 4 in (+) 

19 

20-NCB, AJ1-5 

Channel No. 4 in (-) 

29 

E01-20 

Channel No. 5 shield 

21 

NC 


22 

NC 


23 

NC 


24 

NC 


25 

NC 










TABLE V. - DJI PIN CONNECTIONS - 


DAC (DDA-06) OUTPUT SIGNALS 


Pin 

To 

Function 

1 

AJ2-7 

BIAS No. 5 

2 

AJ2-18 

BIAS No. 4 

3 

E01-24 

ACK to CIM 

4 

ERB-4 

To ERB relay board 

5 

ERB-5 


6 

ERB-6 


7 

ERB-7 


8 

ERB-8 


9 

ERB-9 


10 

ERB-10 


11 

ERB-11 

To ERB relay board 

12 

AJ2-6 

Bias No. 3 

13 

NC 


14 

AJ2-17 

Bias No. 2 

15 

NC 


16 

AJ2-5 

Bias No. 1 

17 

NC 


18 

NC 


19 

NC 


20 

NC 


21 

NC 


22 

AJ1-1 

CIM Ready 

23 

ERB-23 

To ERB relay board 

24 

ERB-24 


25 

ERB-25 


26 

ERB-26 


27 

ERB-27 


28 

ERB-28 


29 

ERB-29 


30 

ERB-30 


31 

ERB-31 


32 

ERB-32 


33 

ERB-33 


34 

ERB-34 


35 

ERB-35 


36 

ERB-36 


37 

ERB-37 

To ERB relay board 







TABLE VI. - E01 PIN COONECTIONS - 
SIMULATOR OUTPUT SIGNALS 


Pin 

To 

Function 

1 

17-CA 

Channel No. 1 out (+) 

2 

17-CB 

Channel No. 1 out (-) 

3 

El 1-3 

Channel No. 2 shield 

4 

19-CA 

Channel No. 3 out (+) 

5 

19-CB 

Channel No. 3 out (-) 

6 

El 1-6 

Channel No. 4 shield 

7 

21-CA 

Channel No. 5 out (+) 

8 

21— CB 

Channel No. 5 out (-) 

9 

NC 


10 

NC 


11 

NC 


12 

NC 


13 

NC 


14 

E 1 1—14 

Channel No. 1 shield 

15 

18-CA 

Channel No. 2 out (+) 

16 

18-CB 

Channel No. 2 out (-) 

17 

E 11—17 

Cahnnel No. 3 shield 

18 

20-CA 

Channel No. 4 out (+) 

19 

20-CB 

Chaneel No..' 4 out (-) 

20 

E 1 1—20 

Channel No. 5 shield 

21 

NC 


22 

NC 


23 

NC 


24 

AJ1-7 

START from CIM (-) 

25 

AJ1-6 

START from CIM (+) 


BNC connector (noise input) 

(+) - MJ1-22 

(-) - 1-NCA, 2-NCA, 3-NCA 
4-NCA, 5-NCA, AJ2-16 
MJI-2 











TABLE VII. - PROGRAM DESCRIPTIONS FOR THE SENSOR FAILURE SIMULATOR PROGRAM 


Program name DOS file name Description 

Cim CIM.ASM FORTRAN callable assembly routine used by SFS to 

begin failure simulation on cue from CIM unit. 

Edit EDIT. FOR FORTRAN subroutine which controls flow of the failure 

scenario editor. 

Edit Description EDITDESC.FOR FORTRAN subroutine which allows user to change 

description of current failure scenario. 

Edit Failures EDITFAIL.FOR FORTRAN subroutine which allows user to define which 

channels of the current scenario will be failed. 

Edit Gains EDITGAIN.FOR FORTRAN subroutine which allows user to define type 

of failure and associated constants for each failed 
channel . 

Edit Save EDITSAVE.FOR FORTRAN subroutine which allows the user to save the 

current failure scenario in a DOS text file before 
existing failure scenario editor. 

Edit Values EDITVALU.FOR FORTRAN subroutine which allows user to modify 

nominal and maximum channel values as well as 
failure delays for the current scenario. 

End of Fil ENDOFFIL.FOR FORTRAN logical function which sets the pointer to 

the end of the currently open scenario file. True 

is returned if no errors, otherwise false is 
returned . 

Erase Screen ERASESCR.FOR FORTRAN subroutine which writes the DOS control code 

for clearing the CRT text screen. 

Get Clock GETCLOCK.ASM FORTRAN callable assembly routine which reads the 

real-time clock on the AST board. Returns as 
integers minutes, seconds, tenths, hundredths, and 
thousandths. 

GETDAT Non-standard FORTRAN callable subroutine whcih 

returns the date from the DOS clock. 

GETTIM Non-standard FORTRAN callable subroutine which 

returns the time from the DOS clock. 

Init 8255 INIT82255.ASM FORTRAN callable assembly routine which initializes 

the 8255 chip on the Metrabyte DDA-06 DAC/parallel 
output board. (Ports A and B initialized as outputs, 
port C initialized as input.). 



TABLE VII. Continued 


Program name 
Init HDWR 

Initialize 

Instructions 

Menu 1 

Menu 2 

Noise CHK 

NonBl ank 

Open File 
Read Instructions 
Read Scenario 
Read Timer 


DOS file name 
INITHDWR.FOR 

INITIAL. FOR 

INSTRUCT. FOR 

MENU1.F0R 

MENU2.F0R 

NOISECHK.FOR 

NONBLANK. FOR 

OPENFILE.FOR 
READINST.FOR 
READSCE.FOR 
ZEROTIME. FOR 

RUN. FOR 


Description 

FORTRAN subroutine which prepares failure hardware 
for transient simulation. Sets scale factor to 1.0 
and bias to 0.0 then trips relays of failed channels. 

FORTRAN subroutine which initailizes values for all 
common blocks. Also calls subroutines which 
initialize the anlaoq hardware (Init 8255 and Init 
HDWR). 

FORTRAN subroutine which calls READ INSTRUCTIONS to 
read DOS text file containing instructions 
(\SFS\INSTRUCT.TXT) then displays the file contents 
on the monitor in an organized fashion. 

FORTRAN subroutine which displays SFS main menu, 
prompts user and returns a correct response to the 
main program. 

FORTRAN subroutine which displays menu controlling 
manipulation of stored scenarios, prompts user and 
returns a correct response to STORE. 

FORTRAN subroutine which checks failure scenario to 
ensure that noise is defined for one channel only. 

If not prompts user for correction. 

FORTRAN integer function whose value is the position 
of the last nonblank character in the character 
variable which is its parameter. 

FORTRAN subroutine used to open failure scenario 
files for reading and writing. 

FORTRAN subroutine which reads DOS text file 
containing insturctions for using the SFS. 

FORTRAN subroutine which reads a scenario (specified 
by number) from the currently open scenario file. 

FORTRAN subroutine which calls GET CLOCK to read the 
real-time clock on the AST board and returns as the 
value of its parameter the elaspsed time (in 
seconds) since the last call to ZERO TIMER. 
Resolution: 0.001 sec. 

FORTRAN subroutine which controls flow of program's 
real-time failure simulation. 


Run 



TABLE VII. Concluded 


Program name DOS file name Description 


Run Reset 

RUNRESET.FOR 

FORTRAN subroutine which forces user to manually 
reset relays for all failed channels to an unfailed 
state at the end of failure simulation. 

Run Setup 

RUNSETUP.FOR 

FORTRAN subroutine which prompts user to initialized 
failure hardware. If positive response, calls INIT 
HDWR . 

Sensor Failure 

SFS. FOR 

FORTRAN MAIN PROGRAM. Controls overall program 
execution. 

SFS Out 

SFSOUT.ASM 

FORTRAN callable assembly routine used for ouput to 
D/A converters, multiplying D/A converters, and 
relays located on the Metrabyte DDA-06, DAC-02, and 
ERB-24 boards respectively. 

Store 

STORE. FOR 

FORTRAN subroutine which controls flow for portion 
of program which stores, retrieves, deletes, 
and replaces scenarios in DOS text files. 

Store Delete 

STOREDEL.FOR 

FORTRAN subroutine which provides capability for user 
to delete a previously stored scenario from a file. 

Store List 

STORELIS.FOR 

FORTRAN subroutine which reads a specified scenario 
file, presents user with a list of scenarios stored 
therein, prompts user for choise and returns number 
of the stored scenario to the calling subroutine. 

Store Replace 

STOREREP.FOR 

FORTRAN subroutine which provides capability to 
replace any given scenario stored in a file with the 
current failure scenario. 

Store Retrieve 

STORERET.FOR 

FORTRAN subroutine which provides capability for user 
to retrieve from a file a previously stored scenario. 

Store Save 

STORESAV.FOR 

FORTRAN subroutine which provides a capability for 
the user to save the current failure scenario in a 
DOS text file. 

Test 

TEST. FOR 

FORTRAN subroutine which allows user to manipulate 
the failure hardware directly from the PC's keyboard. 

Wait 

WAIT. FOR 

FORTRAN subroutine which uses GETTIM to suspend 
program execution for a specified number of seconds. 

Write Scenario 

WRITESCE.FOR 

FORTRAN subroutine which writes the current failure 
scenario to the currently open scenario file. 

Zero Timer 

ZEROTIME. FOR 

FORTRAN subroutine which calls GET CLOCK to read the 
real-time clock on AST board then stores the time of 
day returned by GET CLOCK as the start time of the 
transient. 



TABLE VIII. - COMMON BLOCK DESCRIPTIONS FOR THE SENSOR FAILURE SIMULATOR PROGRAM 


Name of 
common 

DOS file name 

Type 

Description 

(Blank) 

BLANK. CMN 

character 

Contains DOS control codes and special ASCII graphics sequences 

SFS 00 

SFSOO.CMN 

character 

Contains name of default scenario file, file header, current 
scenario description and units for each channel. 

SFS 01 

SFS01.CMN 

integer 

Contains constants for number of channels, number of failures 
per channel and maximum number of scenarios per file. 

SFS 02 

SFS02.CMN 

mixed 

Contains logical and numerical data for the current failure 
scenario. 

Menu 00 

MENUOO.CMN 

character 

Contains title and options used by subroutine menu 1. 

Menu 11 

MENU11.CMN 

character 

Contains description of channel signals for editor. 

Menu 12 

MENU12.CMN 

character 

Contains description of failure modes for editor. 

Menu 21 

MENU21.CMN 

character 

Contains description of options for the stored scenario menu. 

Hardware 

HARDWARE. CMN 

integer 

Contains device designations for the various pieces of D/A 
hardware. 



TABLE IX. - HIERARCHICAL STRUCTURE OF THE SENSOR FAILURE SIMULATOR PROGRAN 



Sensor 

Failure 

Simulator Initialize Init 8255 

Init HDWR SFS Out 

Erase Screen 

Menu 1 Erase Screen 

NonBlank 

Instructions Read Instructions 
Erase Screen 
Store Erase Screen 

Menu 2 

Store Retrieve Open File NonBlank 

Store List 

Read Scenario NonBlank 

Wait GETTIM 

Store delete Open File NonBlank 

Store List 
NonBlank 

Store Replace Open File NonBlank 

Store List 

Write Scenario GETDAT 
GETTIM 
NonBlank 

NonBlank 

Store Save Open File NonBlank 

End of File 

Write Scenario GETDAT 
GETTIM 
NonBlank 

NonBlank 

Edit Erase Screen 

Edit Description NonBlank 
Edit Failure 






TABLE IX. - HIERARCHICAL STRUCTURE OF THE SENSOR FAILURE SIMULATOR PROGRAN 

(concluded) 


Level 1 

! 

Level 2 

Level 3 

Level 4 


Edit Values 
Edit Gains 
Noise Check 
Edit Save 

Open File 

NonBlank 



End of File 
Write Scenario 

GETDAT 

GETTIM 

NonBlank 



NonBlank 

Wait 

GETTIM 

Run 

Erase Screen 




Run Setup 
CIM 

Init HDWR 

SFS Out 


Zero Timer 

Get Clock 



Read Timer 

Get Clock 



(Zero Timer) 
SFS Out 
Run Reset 

SFS Out 


Test 

Erase Screen 
SFS Out 




Level 5 











TABLE X. - EDITOR FUNCTION KEYS AND CODES 


Key 

Code 

Function 

FI 

ml<CR> a 

display scenario description menu 

F2 

m6<CR> 

display failed channels menu 

F3 

m2<CR> 

display nominal values menu 

F4 

m7<CR> 

display maximum values menu 

F5 

m3<CR> 

display failure delay menu 

F6 

m8<CR> 

display channel 1 failure modes 

F7 

m4<CR> 

display channel 2 failure modes 

F8 

m9<CR> 

display channel 3 failure modes 

F9 

m5<CR> 

display channel 4 failure modes 

FIO 

mO<CR> 

display channel 5 failure modes 

Home 

mO<CR> 

display scenario description menu 

PgUp 

b<CR> 

display previous menu 

PgDn 

f<CR> 

display next menu 

End 

mx<CR> 

save scenario and exit editor 

t 

u<CR> 

move up one menu item 

1 

d<CR> 

move down one menu item 


a <CR> denotes a carriage return (ASCII decimal code 13) 








TABLE XI. - DOS BATCH FILE SFS BAT 


Line no. 


DOS Command line 


1 echo off 

2 break off 

3 path D:\sfs;D:\DOS;D:\utility 
cd\scenario 

if 1 %1 1 = ='/d'; dir *.sce > LPT1 
if '%1' = = * /D ' ; dir *.sce > LPT1 
SFS 
cd\ 

break on 







TABLE XII. - SPECIAL CODES FOR INSTRUCTION TEXT FILE 


Code 

Translation 

$5 

dollar sign (5) 

$e 

escape character, ASCII decimal code 27 

%f 

control sequence which causes subsequent test 
to flash (blink) 

$b 

control sequence which causes subsequent text 
to appear bold (high intensity) 

lr 

control sequence which causes subsequent text 
to appear in reverse video (dark on light) 

$n 

control sequence which causes subsequent text 
to appear in normal video (non-flashing, 
normal intensity, light on dark) 

$c§W 

ASCII Character specified by ###, where 
is a three digit integer between 000 and 255 





Engine 

sensor 

SIGNAL 


Gain Ramp + step Random noise 



Failed 

sensor 

SIGNAL 


Scale Bias Noise 


Figure 1. - Method of failure modeling. 


Engine 

sensor 

SIGNALS 



Modified 

sensor 

signals 


Figure 2. - General conceptual design. 



Differential 
signals TO 
DIA (5) 


CIM Start 
signal 


Figure 3. - Block diagram of SFS hardware design. 

















Connectors 



Figure A. - Typical (channel 1) clipping-summing amplifier. 



Asp Auxiliary 
connector 


Asp Board 


DDA-02 Board 
(MDAC-C) 


DDA-02 Board 
(MDAC-B) 


DDA-02 Board 
(MDAC-A) 


DDA-06 Board 


PC Interface 
board 


Figure 5. - PC expansion chassis layout. 


Signal fro 
CIM's DAC 


Ready signal to SFS 





Ready signal from CIM 
(double-ended) 


Shields 


Modified sensor signals 
(Double-ended) 


Engine sensor signals 
(double-ended) 

Shields 


Engine sensor signals 
(signal-ended) 

Scaled sensor signal 
Bias error component 
Noise error component 


Figure 6. - Block diagram of asp board. 



Figure 7. - Comparator circuit for Cl M /protoboard communications. 











Figure 8. - ERB chassis end panel. 




Figure 9. - General conceptual design of SFS software. 


***************************** 
* * 

* Sensor Failure Simulator * 

* * 

* MAIN MENU * 

* * 
***************************** 


1) 

INSTRUCTIONS 



2) 

RETRIEVE 

Stored 

Failure 

Scenario 

3) 

EDIT . . . 

Current 

Failure 

Scenario 

4) 

Run .... 

Current 

Failure 

Scenario 

5) 

TEST . . . 

SFS Hardware/Software 

6) 

QUIT 





YOUR CHOICE? 

Figure 10. - Sensor failure simulator main menu. 










************** 


************ 


HOW TO USE THESE INSTRUCTIONS 


Welcome to the Sensor Failure Simulator! You have just accessed 
the on-line instruction file. This file describes the operation of the 
Sensor Failure Simulator (refered to as the SFS in the remaining pages 
of this documentation) . 

These instructions consist of a number of pages of text. You may 
page up and down through the text by pressing the PgUp and PgDn keys. 

To return to this menu, press the Home key. To view the last page of 
this text press the End key. You may exit the on-line instruction mode 
at any time by pressing the carriage return/enter key. If later you 
decide to return for more instruction, the program will automatically 
begin with the page at which instruction was previouly terminated. 

Enter a PgDn to proceed to the introduction. 

Figure 11. - First page of on-line instructions. 


Sensor Failure Simulator 
STORED SCENARIO MENU 


* * * * * 


Current Scenario Description Shown Here 


1) 

RETRIEVE 

Stored 

Failure 

Scenario 

2) 

DELETE 

Stored 

Failure 

Scenario 

3) 

REPLACE 

Stored 

Failure 

Scenario 

■*) 

STORE 

Current 

Failure 

Scenario 

5) 

Return to Main Menu 



YOUR CHOICE? 

Figure 12. - SFS stored scenario menu. 


*********************** 

Sensor Failure Simulator 
STORED SCENARIO MENU 

*********************** 

Current Scenario Description Shown Here 


0) 

N1 

Step 

Failure: 

1000 

rpm @ 0.5 

sec 


22NOV85 

1) 

N1 

Ramp 

Failure: 

200 

rpm/sec @ 

1.0 

sec 

22NOV85 

2) 

N2 

Step 

Failure: 

1500 

rpm @ 1.0 

sec 


25NOV85 

3) 

N2 

Ramp 

Failure: 

250 

rpm/sec @ 

1.5 

sec 

25NOV85 

4) 

N3 

Step 

Failure: 

1000 

rpm @ 0.5 

sec 


29NOV85 

5) 

N3 

Ramp 

Failure: 

200 

rpm/sec @ 

1.0 

sec 

29NOV85 

6) 

N4 

Step 

Failure: 

1500 

rpm @ l.o 

sec 


05DEC85 

7) 

N4 

Ramp 

Failure: 

250 

rpm/sec @ 

1.5 

sec 

05DEC85 

8) 

N5 

Step 

Failure: 

1500 

rpm @ 0.5 

sec 


10DEC85 

9) 

N5 

Ramp 

Failure: 

250 

rpm/sec @ 

1.0 

sec 

10DEC85 

:er : 

: Value 

or +-> 







Figure 13. - Typical menu of stored scenario descriptions. 


************************** 

Sensor Failure Simulator 
FAILURE SCENARIO EDITOR 

************************** 

Enter A 45 Character Description Of The Scenario: 

0 5 10 15 20 25 30 35 40 45 

Sensor Failure Simulator Default Scenario 

Figure 1R. - Entering the failure scenario editor. 


***************************** 
* * 

* Sensor Failure Simulator * 

* * 

* FAILURE SCENARIO EDITOR * 

* * 
***************************** 

* * Sensor Failure Simulator Default Scenario * * 


************************** 

* 

* Sensor Failure Simulator 

* 

* FAILURE SCENARIO EDITOR 

* 

************************** 

* * Sensor Failure Simulator Default Scenario 


Channels To Be Failed Are Displayed IN Bold Type: 


Define The Nominal Value For Each Failed Channel: 


Channel 1) 
Channel 2) 
Channel 3) 
Channel 4) 
Channel 5) 


Low Spool 
High Spool 
Combustor 
Low turbine 
Low Turbine 


Shaft Speed 
Shaft Speed 
Exit Pressure 
Exit Pressure 
Inlet Temperature 


Channel 1: 
Channel 2: 
Channel 3: 
Channel 4: 
Channel 5: 


Low Spool 
High Spool 
Combustor 
Low Turbine 
Low Turbine 


Shaft Speed 
Shaft Speed = 

Exit Pressure = 

Exit Pressure = 

Inlet Temperature = 


10000.00 RPM* 

13000.00 RPM 

400.0000 PSI 

50.00000 PSI 

1700.000 * F 


Toggle On/Off By Channel Number or I : 


Enter: Value or ^ — *: 


Figure 15. - Failed channels menu. 


Figure 16. - Menu for nominal channel values. 
Values shown are for illustration only. 



*********************'******** 


***************************** 


* Sensor Failure Simulator * 

* * 

* FAILURE SCENARIO EDITOR * 

* * 
***************************** 


Sensor Failure Simulator * 

* 

FAILURE SCENARIO EDITOR * 

* 

*********************** 


* * Sensor Failure Simulator Default Scenario 


Sensor Failure Simulator Default Scenario * * 


Define The Maximum Value For Each Failed Channel: 


Define The Failure Delay For Each Failed channel: 


Channel 

1: 

Low Spool 

Shaft Speed 

. 

15000.00 

RPM* 

Channel 

1: 

Low Spool 

Shaft 

Speed 


0 . OOOOOE+OO 

SEC 

Channel 

2: 

High Spool 

Shaft 

Speed 

= 

15000.00 

RPM 

Channel 

2: 

High Spool 

Shaft Speed 

= 

0 . 00000E+00 

SEC 

Channel 

3: 

Combustor 

Exit 

Pressure 

- 

600.0000 

PSI 

Channel 

3: 

Combustor 

Exit 

Pressure 

- 

0. 00000E+00 

SEC 

Channel 

4: 

Low Turbine 

Exit 

Pressure 

- 

100.0000 

PSI 

Channel 

4: 

Low Turbine 

Exit 

Pressure 

= 

0. OOOOOE+OO 

SEC 

Channel 

5: 

Low Turbine 

Inlet 

Temperature 

“ 

2500.000 

*F 

Channel 

5: 

Low Turbine 

Inlet 

Temperature 

= 

0. 00000E+00 

SEC 


Enter: Value or 


Enter: Value or ^ — l : 


Figure 17. - Menu for maximum channel values. 
Values shown are for illustration only. 


Figure 18. - Failure delay menu. 


***************************** 
* * 

* Sensor Failure Simulator * 

* * 

* FAILURE SCENARIO EDITOR * 

* * 
***************************** 

* * Sensor Failure Simulator Default Scenario * * 


***************************** 


******* 


Sensor Failure Simulator 
FAILURE SCENARIO EDITOR 

************* 


* * * 


Sensor Failure simulator Default Scenario * * 


Channel 1 Active Failures Are In Bold Type: 


1) 

Scale Factor = [ 

1.000000 

] 

2) 

Bias = [ 

O.OOOOOOOE+OO 

RPM ) 

3) 

Ramp = [ 

0. 0000000 E+OO 

RPM/ sec 

4) 

Noise s.F. = [ 

O.OOOOOOOE+OO 

3 


Based On Failure Gains 

Channel Value Will Exceed User Defined Limits: 

A) User Defined Maximum = 15000.00 

B) Calculated Maximum = 15501.00 


Toggle On/Off By Number [, Value] or J : 

Figure 19. - Typical menu of failure modes and constants. 


Change "A" to "B" ? Y 

Figure 20. - Maximum channel value exceeded. 


********************** 

* 

* Sensor Failure Simulator 

* 

* FAILURE SCENARIO EDITOR 

* 

********************** 


***** 


Sensor Failure Simulator Default Scenario * * 


Ramp Failure Will Peak At Approx. 

0 minutes 
8 seconds 

Is This Acceptable? Y 

Figure 21. - Typical display for active ramp failure. 


************************** 

* 

Sensor Failure Simulator * 

* 

FAILURE SCENARIO EDITOR * 

* 

************************** 

Sensor Failure Simulator Default Scenario * * 


Noise Is Allowed On One Channel Only. 
It Has Been Defined On 3 Channels: 

Channel 1 
Channel 2 
Channel 4 


Which One Channel Should Be Failed? 

Figure 22. - Typical display for noise failure on 

MULTIPLE CHANNELS. 



Sensor Failure Simulator 


RUNNING FAILURE SCENARIO 


HOME = SCENARIO DESCRIPTION 
PGUP = PREVIOUS MENU 
PGDN = NEXT MENU 
END = EXIT EDITOR 


Sensor Failure Simulator Default Scenario 


Initialize Sensor Failure Hardware? Y 


Figure 23. - SFS function key template. 


Figure 24. - Query to initialize failure hardware. 


******** 


********** 


Sensor Failure Simulator 


Sensor Failure Simulator 


RUNNING FAILURE SCENARIO 


Sensor Failure Simulator Default Scenario 


RUNNING FAILURE SCENARIO 


Sensor Failure Simulator Default Scenario 


Ready To Begin Failure Scenario: 

1) Begin Scenario 

2) Begin Scenario on signal from CIM 

3) Return To Main Menu 


How Many Seconds Should The Scenario Run? 
<default=20 . 00 > 


Figure 25. - Query for length of simulation. 


Enter Run Option: 

Figure 26. - Query for simulation start signal. 


************* 


********** 


********** 


Sensor Failure Simulator 


RUNNING FAILURE SCENARIO 


Sensor Failure Simulator 


RUNNING FAILURE SCENARIO 


Sensor Failure Simulator Default Scenario 


Sensor Failure Simulator Default Scenario 


** RUNNING ** 


Waiting For Signal From CIM _____ 

Star "*'* Appears When Transient Begins 


Figure 27. - Signal for execution of user initiated 

REAL-TIME FAILURE SIMULATION. 


Figure 28. - Signal for CIM initiated real-time 

FAILURE SIMULATION. 










************************* 

* 

Sensor Failure Simulator * 

* 

RUNNING FAILURE SCENARIO * 

* 

************************* 

Sensor Failure Simulator Default Scenario * * 


************* 
* 

Simulator * 

* 

* RUNNING FAILURE SCENARIO * 

* * 
***************************** 

* * Sensor Failure Simulator Default Scenario * * 


******** 

Sensor Failure 


Finished Running at 20.000 seconds 


Maximum Delta T is 0.002 seconds. 

Maximum Delta T at 19.997 seconds. 
Average Delta T is 0.001 seconds. 


*** HIT ' TO CONTINUE *** 

Figure 29. - Display of run time statistics. 


Manual Reset of Failed Channels ( Bold Typed ) : 

Channel 1) Low Spool Shaft Speed 
Channel 2) High Spool Shaft Speed 
Channel 3) Combustor Exit Pressure 
Channel 4) Low turbine Exit Pressure 
Channel 5) Low Turbine Inlet Temperature 


Toggle Off By Channel Number: 


Figure 30. - Typical menu for manual reset of failed 
CHANNELS. 


***** 


*************** 
Sensor Failure simulator 
TEST MENU 

*************** 


0) 

Noise 

DAC-02/MDAC0 





1) 

Scale 

DAC-02/MDAC1 

11) 

Noise 

Relay 

1/PA1 

2) 

Scale 

DAC- 0 2/MDAC2 

12) 

Noise 

Relay 

2/PA2 

3) 

Scale 

DAC-02/MDAC3 

13) 

Noise 

Relay 

3/PA3 

4) 

Scale 

DAC-02/MDAC4 

14) 

Noise 

Relay 

4/PA4 

5) 

Scale 

DAC-02/MDAC5 

15) 

Noise 

Relay 

5/PB5 

6) 

Bias 

DDA-06/DA1 

16) 

Failure 

Relay 

1/PB1 

7) 

Bias 

DDA-06/DA2 

17) 

Failure 

Relay 

2/PB2 

8) 

Bias 

DDA-06/DA3 

18) 

Failure 

Relay 

3/PB3 

9) 

Bias 

DDA-06/DA4 

19) 

Failure 

Relay 

4/PB4 

10) 

Bias 

DDA-06/DA5 

20) 

Failure 

Relay 

5/PB5 


Enter Number To Toggle (exit-99) : 


Figure 31. - Typical menu for manually controlling hardware 
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